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METHOD AND APPARATUS FOR GENERATING AND PLAYING 
DIAGNOSTIC MESSAGES INDICATIVE OF MTA PROVISIONING STATUS 

5 FIELD OF THE INVENTION 

The present invention relates to cable modems with embedded media terminal 
adaptors, and more particularly, to a media terminal adaptor (MTA) that determines 
provisioning failure or an out-of-service condition and generates an appropriate 
10 diagnostic audio voice message or tone sequence through a telephone handset 
instructing the listener on how to proceed in order to resolve the provisioning failure 
or the out-of-service condition. 

BACKGROUND OF THE INVENTION 

15 Media terminal adaptors (MTAs) are used to convert digital data to analog 

audio for telephones. MTAs require a strict provisioning sequence prior to becoming 
operational. In a PacketCable environment a total of 25 steps must be complete to 
become operational, and 1 1 additional steps must be completed in order to establish 
security associations with the call agent. These provisioning steps are controlled by 

20 the Multiple Service Operator (MSO) or Internet Service Provider (ISP) and are a 
function of the MSO Provisioning Server (MTA dynamic host configuration protocol 
(DHCP) options and MTA configuration file), the service provider's domain name 
system (DNS) configuration, and the configuration of the service provider call agent 
and Kerberos Key Distribution Center (KDC). Failure to properly configure any of 

25 these items can leave the MTA in a non-provisioned or improperly configured state 
which will render the MTA nonfunctional or out-of-service. In this context, out-of- 
service means that dial tone is not heard on the handset when the phone attached to 
the MTA is taken off-hook. 

Existing cable modems and MTAs use discrete light emitting diodes (LEDs) or 

30 a 7-segment LED display to indicate provisioning status and possibly, the first 
provisioning step that has failed. Due to the small number of product LEDs (typically 
5, 6, or 7-segment display) and the large number of provisioning steps, it is difficult to 
indicate the precise cause of a provisioning failure. Approaches have been used to 
display the provisioning status via blinking LEDs, displaying the status code in a 
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binary format, etc. Many non-technical consumers are not able to easily correlate the 
blinking LED codes with a table in the user manual in order to resolve their specific 
problem. 

As can be appreciated, there is a need for a MTA that provides a diagnostic 
5 audio message that is easily understandable to the user of the MTA when a there is a 
provisioning failure or out-or-order condition. Additionally, there is a need to provide 
a message to the user that the user can easily understand with regard to correcting 
the provisioning failure or out-of-order condition. 

10 SUMMARY OF THE INVENTION 

In accordance with the present invention, if a phone is taken off-hook on a 
MTA that is not provisioned, improperly provisioned, or placed in an out-of-service 
state such as by the service provider, the MTA will generate an appropriate 
diagnostic audio voice message or tone sequence to the telephone informing the 

15 user of the failure or out-of-order condition and instructing the listener on how to 
proceed in order to resolve the problem. 



BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 illustrates a general block diagram of a media terminal adaptor (MTA) in 
20 accordance with the present invention. 

DETAILED DESCRIPTION OF THE PRESENT INVENTION 
The present invention provides several methods to indicate to the user in a 
readily understandable manner that the MTA 10 has not been properly configured 
25 and the steps the user should take to correct the condition, for example, by 
contacting their service provider to resolve the issue. These methods involve playing 
an audio sequence consisting of a voice message and/or a sequence of audio tones 
to indicate the specific problem and what to do to resolve the issue. 

The communications by MTA 10, like cable modems, with a communications 
30 network 5, such as without limitation an Internet protocol based cable network, is well 
known. Therefore, no further description as related to such communications of the 
MTA 10 with a communications network 5 is needed. However, for the sake of 
facilitating an understanding of certain aspects of the present invention, an 
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explanation of the MTA 10 in accordance with the present invention is described 
herein below. 

Referring now to FIG. 1, the MTA 10 of the present invention includes a digital 
signal processor (DSP) 12 and plain old telephone service (POTS) endpoint circuitry 

5 14, speech decoder 20 and display 22. The DSP 12 includes an input jitter buffer 38. 
The MTA 10 stores audible and/or DTMF tone sequences in a tone sequence file 18 
and audio messages in an audio message file 16. 

The MTA 10 also accesses a normal mode configuration file 28 for operating 
the MTA when properly provisioned, an out-of-service configuration file 30 which 

10 enables the service provider to place the MTA 1 0 out-of-service, a provisioning failure 
detector 32 and provisioning failure resolver 34. As can be appreciated, the normal 
mode configuration file 28 defines the operational protocol of a properly provisioned 
MTA 10 to communicate with the communications network 5 to which it is attached. 

The MTA 10 uses discrete LEDs or a 7-segment LED display 22 to indicate 

15 provisioning status and possibly, the first provisioning step that has failed, as 
determined by the provisioning failure detector 32. Display 22 may be used to 
display the provisioning status via blinking LEDs, displaying the status code in a 
binary format, etc. In the present invention, the MTA 10 also generates an audible 
diagnostic message to the user, over the attached telephone(s) 50 via handset 54, 

20 indicating: 1) the presence of a provisioning error, as determined by the provisioning 
failure detector 32; 2) the nature of the error (which provisioning step failed); and 3) 
what step should be taken to resolve the error, as determined by the provisioning 
failure resolver 34. For example, the error or failure detected by the provisioning 
failure detector 32 would be mapped to a resolution or corrective action to be taken 

25 by the user, as determined by the provisioning failure resolver 34. Such corrective 
action would be provided to the user/listener in the form of an audible message. 
The user may be directed to receive the diagnostic message via handset 54 by, for 
example, an indication on MTA 1 0, 

In the present invention, the audible message can consist of either a voice 

30 message stored in the audio message file 16 or a sequence of audio tones stored in 
the tone sequence file 18, or both. The voice message and/or audio tone sequence 
can be either canned (fixed, stored in local non-volatile memory) or dynamically 
generated. The audio clip could combine fixed voice audio with dynamically- 
generated voice audio such as a specific telephone number to dial. The variable 
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information (VI) used to generate the dynamic portion of the message could be stored 
in non-volatile memory or passed to the MTA 10 via a proprietary configuration file 
TLV or management information base (MIB) element. In this way, the diagnostic 
message can be tailored for a specific service provider (service provider name and 
5 telephone number), location information, etc. 

In addition to or alternately, a sequence of audio tones (including a 'beep' 
sequence or a series of DTMF tones or modem tones) stored in the tone sequence 
file 18 could be played to convey the diagnostic audible message. DTMF tones would 
be suitable for machine recognition, by, for example, test equipment used by a field 
10 technician. The MTA could detect whether the test equipment is connected, for 
example, by entering a tone mode using a predefined key sequence on the phone 
keypad. 

In addition to or alternatively, the telephone keypad 52 can be used to request 
additional diagnostic or status information from a diagnostic and status information 

15 module 36. The generated audible message can prompt the user/listener to enter 
one or more keypad digits in order to retrieve more detailed diagnostic information or 
status information from such diagnostic and status information module 36. The MTA 
operating status information can include, without limitation, the current upstream and 
downstream frequency, power level, and signal to noise ratio. 

20 The improved operation of the MTA 10 will now be described in detail. The 

MTA's DSP (digital signal processor) 12 and POTS endpoint circuitry 14 are enabled 
early in the boot-up sequence, prior to the start of the MTA's provisioning. If the 
MTA's provisioning is successful, the MTA 10 enters its normal operating mode. 
Thereby, when the user takes the phone handset off-hook, which is detected by the 

25 off-hook detector 26, the user/listener hears the dial tone. In other words, the POTS 
endpoint circuitry 14 sends an audio dial tone signal to the telephone 50. 

On the other hand, if the MTA's provisioning was not successful or if the 
service provider placed the MTA in an out-of-service state via the MTA's out-of- 
service configuration file 30 or MTA's MIB element setting, as detected by the 

30 provisioning failure detector 32, the MTA 10 will play an appropriate diagnostic audio 
message (voice and/or tone sequence) when the user takes the phone off-hook, as 
detected by the off-hook detector 26. 

As previously described, provisioning of the MTA 10 requires, without 
limitation, various steps to establish security associations with a call agent and those 
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steps for establish communications with a service provider Provisioning Server using 
DHCP options, a service provider's DNS configuration, and the configuration of the 
service provider call agent and/or and the KDC. A few examples of errors or failures 
detected by the provisioning failure detector 32 would include whether: 1) the 

5 securing associations are established; 2) the DHCP options are defined; 3) the DNS 
configuration is defined; 4) the TFTP server configuration is defined; 5) the SNMP 
entity configuration is defined; 6) the Kerberos server configuration is defined; and 7) 
an out-of-service condition exists. Nevertheless, all steps required to make a MTA 1 0 
operational with a communication network 5 would need to be checked for failure of 

10 any one provisioning step. 

Regarding the message generation, the MTA 10 will generate audio message 
from the audio message file 16 or tone sequence file 18 by various techniques. One 
possible method is to encapsulate the audio in an RTP (real time protocol, RFC- 
1889/1890) packet stream to emulate the reception of said data from the 

15 communication network 5. In this example, the audio packet stream comprises an 
ordered sequence of near-synchronous RTP packets and is sent to the DSP 12 and 
the POTS endpoint circuitry 14. As with audio packets received from the 
communications network 5, the DSP 12 depacketizes the RTP packet stream having 
the audio data and places it in its inbound jitter buffer 38 for use by the speech 

20 decoder 20. 

The message playing is effectuated as the speech decoder 20 converts the 
digital pulse code modulation (PCM) audio data to analog samples, which are 
reconstructed in the POTS endpoint circuitry 14 and played to the listener through the 
handset 54. 

25 Thus, the DSP 12, POTS endpoint circuitry 14 and speech decoder 20 in 

combination with the audio message file 16 and tone sequence file 18 provide the 
means for generating and playing the provisioning error messages. 

The existing POTS endpoint circuitry 14 and control software (off-hook 
detector 26) monitor the telephone's hook state and generate the diagnostic audio 

30 message when an off-hook condition is detected by lifting handset 54. As can be 
appreciated, conventionally, a telephone 50 can be taken off-hook by pressing a 
speakerphone button. Therefore, the diagnostic audio message would be played 
through the speaker on the base of the telephone 50. 
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Since there are numerous diagnostic audio messages, describing all possible 
messages is prohibitive. Therefore, a few examples of diagnostic audio messages 
are described in TABLE 1 below to permit understanding of the present invention. 

TABLE 1 



10 



ERROR CONDITION 
Unable to obtain IP address 



MESSAGE 
"Your MTA cannot obtain a network 
address. Please contact XYZ Cable 
Company at 317-587-3168." Thank 
you." 



15 



Missing DHCP options 



"Your MTA requires one or more 
missing DHCP options. Please 
contact XYZ Cable Company at 317- 
587-3168." Thank you." 



20 



MTA is provisioned 
but not enabled 



"Your MTA has been 
administratively disabled. Please 
contact XYZ Cable Company at 317- 
587-3168." Thank you." 



Numerous modifications to and alternative embodiments of the present 
25 invention will be apparent to those skilled in the art in view of the foregoing 
description. Accordingly, this description is to be construed as illustrative only and is 
for the purpose of teaching those skilled in the art in carrying out the invention. 
Details of the embodiment may be varied without departing from the spirit of the 
invention, and the exclusive use of all modifications, which come within the scope of 
30 the appended claims is reserved. 



